Draft

OGC Best Practice

OGC CityGML Implementation Guidance (Best Practice)
Tamrat Belayneh, Esri Editor Luis Gisler, Esri Editor
Version: 1.0
Additional Formats: XML PDF DOC
OGC Best Practice

Draft

Document number:24-999
Document type:OGC Best Practice
Document subtype:General
Document stage:Draft
Document language:English

License Agreement

Use of this document is subject to the license agreement at https://www.ogc.org/license




I.  Abstract

The CityGML Best Practices Document aims to address fragmentation and inconsistency in CityGML implementations by providing a standardized approach that consolidates frequently used aspects of CityGML. This document seeks to increase CityGML adoption, enhance interoperability, and offer a template for cities to publish consistent CityGML data while harmonizing various encodings and implementations.

It focuses on reducing fragmentation by selecting and promoting the most commonly used elements of CityGML, mitigating challenges posed by diverse modules, Levels of Detail (LODs), and geometric definitions. The document also addresses interoperability issues stemming from heterogeneous software support and aims to avoid redundancy by standardizing profiles, thus promoting consistency and efficiency.

Inspired by existing industry trends and use cases, such as the ADV profile in Germany and 3CIM in Sweden, the CityGML Best Practices Document will use CityGML 3.0 and CityJSON-supported features as a baseline. It will develop a minimal template covering key elements like buildings, street furniture, bridges, and vegetation. The document will be created in consultation with cities with established CityGML workflows to ensure it meets practical, real-world requirements.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, CityGML, CityJSON, 3D


III.  Preface

In March 2024, during the 128th OGC Member Meeting in Delft, Netherlands, discussions began among members and co-chairs of the 3DIM, Geo for Metaverse, Urban Digital Twins DWGs, and the CityGML SWG about the need for an OGC profile or best practice document to address fragmentation and inconsistency in CityGML implementations. This led to a formal proposal presented at the 129th OGC Member Meeting in Montreal, Canada, advocating for a standardized approach to consolidate frequently used aspects of CityGML.

The proposed CityGML Best Practices Document aims to enhance adoption, improve interoperability, and provide a consistent template for publishing CityGML data while harmonizing various encodings and implementations. It focuses on reducing fragmentation by standardizing the most commonly used elements of CityGML, addressing interoperability issues from diverse software support, and avoiding redundancy through standardized profiles.

Drawing on existing industry trends and use cases, such as the ADV profile in Germany and 3CIM in Sweden, the document will use CityGML 3.0 and CityJSON-supported features as a baseline. It will provide a minimal template for key elements like buildings, street furniture, bridges, and vegetation, and will be developed in consultation with cities with established CityGML workflows to ensure it meets real-world needs.

IV.  Security Considerations

No security considerations have been made for this Standard.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

  • Esri
  • HFT
  • TU Delft
  • Virtual City Systems
  • Conterra

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

NameAffiliationOGC member
Tamrat BelaynehEsri, USAYes
Volker CoorsHFT, GermanyYes
Hugo Ledoux, Jantien StoterTU Delft, NetherlandsYes
Claus NagelVirtual City Systems , GermanyYes
Christian DahmenConterra , GermanyYes

VII.  Contributors

Additional contributors to this Standard include the following:

Rob Atkinson, OGC

1.  Scope

This document provides best practices for effectively using CityGML, with a focus on its application across a range of scenarios frequently encountered by cities and municipalities. It is designed to guide the use of CityGML as a robust data model for storing geometric information related to the built environment within a 3D System of Records.

Interoperability

  • This best practice document aims to enhance interoperability between various software packages, facilitating seamless integration and implementation of CityGML for developers. By standardizing practices, it supports consistent and efficient use across different platforms and applications.

  • The document is tailored to address the most common use cases for CityGML, particularly the storage and management of geometric data concerning the built environment in a comprehensive 3D warehouse.

The document adopts a semantically minimal approach, focusing exclusively on attributes directly related to built objects. This approach ensures clarity and avoids unnecessary complexity. It acknowledges that cities may use additional, specialized systems to manage other types of data, such as demographics, traffic flows, and similar information. As such, this best practice document does not encompass these areas but provides the flexibility for implementers to connect to external resources or extend the profile to suit specific needs.

2.  Conformance

This Best Practice defines XXXX.

Requirements for N standardization target types are considered:

  • AAAA

  • BBBB

Conformance with this Best Practice shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC® interface Best Practice, a software implementation shall choose to implement:

  • Any one of the conformance levels specified in Annex A (normative).

  • Any one of the Distributed Computing Platform profiles specified in Annexes TBD through TBD (normative).

All requirements-classes and conformance-classes described in this document are owned by the documents(s) identified.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Identification of Common Molecular Subsequences. Smith, T.F., Waterman, M.S., J. Mol. Biol. 147, 195–197 (1981)

ZIB Structure Prediction Pipeline: Composing a Complex Biological Workflow through Web Services. May, P., Ehrlich, H.C., Steinke, T. In: Nagel, W.E., Walter, W.V., Lehner, W. (eds.) Euro-Par 2006. LNCS, vol. 4128, pp. 1148–1158. Springer, Heidelberg (2006)

The Grid: Blueprint for a New Computing Infrastructure., Foster, I., Kesselman, C.. Morgan Kaufmann, San Francisco (1999).

Grid Information Services for Distributed Resource Sharing. Czajkowski, K., Fitzgerald, S., Foster, I., Kesselman, C. In: 10th IEEE International Symposium on High Performance Distributed Computing, pp. 181–184. IEEE Press, New York (2001)

The Physiology of the Grid: an Open Grid Services Architecture for Distributed Systems Integration. Foster, I., Kesselman, C., Nick, J., Tuecke, S. Technical report, Global Grid Forum (2002)

National Center for Biotechnology Information, http://www.ncbi.nlm.nih.gov

ISO: ISO 19101-1:2014, Geographic information — Reference model — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/59164.html.

ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html.

ISO: ISO 19157:2013, Geographic information  — Data quality. International Organization for Standardization, Geneva (2013). https://www.iso.org/standard/32575.html.

ISO: ISO 19139:2007, Geographic information — Metadata — XML schema implementation. ISO (2007).

ISO: ISO 19115-3, Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts. International Organization for Standardization, Geneva https://www.iso.org/standard/80874.html.

Joan Masó and Lucy Bastin: OGC 15-097r1, OGC® Geospatial User Feedback Standard: Conceptual Model. Open Geospatial Consortium (2016). http://www.opengis.net/doc/IS/guf-conceptual/1.0.0.

Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard. Open Geospatial Consortium (2012). http://www.opengis.net/spec/citygml/2.0.

Jiyeong Lee, Ki-Joune Li, Sisi Zlatanova, Thomas H. Kolbe, Claus Nagel, Thomas Becker: OGC 14-005r3, OGC® IndoorGML. Open Geospatial Consortium (2014). http://www.opengis.net/doc/IS/indoorgml/1.0.0.

Arliss Whiteside Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010).

4.  Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

term used for exemplary purposes

Note 1 to entry: An example note.

Example

Here’s an example of an example term.

[SOURCE: ISO 19101-1:2014]

5.  Conventions

This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1.  Identifiers

The normative provisions in this document are denoted by the URI

http://www.opengis.net/spec/{standard}/{m.n}

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

6.  Clauses not Containing Normative Material

Paragraph

6.1.  Clauses not containing normative material sub-clause 1

Paragraph

General Principles:

  • Flat representation (similar to 3DCityDB & CityJSON) → not really profile

  • Semanticall Thin (link to external sources, rather than copyying in)

  • Avoid Reduancy (if better sources are usually available, i.e. terrain, road)

7.  Real World Use Cases / Applications

This section describes common real world use cases (used in practice or planned for) for the use of Urban Digital Twins Profile by cities and planning authorities. These Use Cases also serve as a basis for the subset definition of the profile.

7.1.  Planning

7.1.1.  Urban Plan Communication

Required: Buildings Benefitial: High LODs, Textures

7.1.2.  Urban Planning / Comprehensive Planning

Overview of projects accross cities (permiting building status) SOR of planned projects

Manage KPIs such as GFA Mix, FAR etc.

Requires: Status of Projects, Units, Storeys

Required Modules: Buildings, Construction Optional Modules:

7.2.  Simulation & Analysis

7.2.2.  Solar Potential & Solar Irradiance

The estimation of the solar potential for roofs and facades is an often cited application for 3D City Models and many cities …​.

7.2.3.  Daylight Simulations

In some countries, Daylight simulations are part of the urban planning or building permit process.

  • To assess the impact of a new construction on daylight in existing buildings in the neighborhood

  • To assess if requirements for daylight are met in a new buildings

The latter is usually conducted using architectural tools, using a detailed 3D model of the building in question (i.e. BIM) and less detailed models of the surrounding context. In this case, the 3D City Model only serves as a source for context and does not require detailed information on rooms or windows.

The first case typically includes the calculation of solar irradiation at window level of surrounding buildings. This requires information about the position and size of the the windows. Currently, most cities do not have this information available for existing (older) buildings.

Relevant Modules: Buildings Required Information: Windows

7.2.4.  Noise Simulation

Noise Simulations become increasingly important as part of the urban planning process. The simulation input is usually noise sources and obstacles from which the propagation of noise is calculated.

3D City models are a useful foundation for the calculation of noise propagation as they include physical obstacles (buildings, sound barriers, vegetation) and potentially also include information about the acoustic properties of horizontal and vertical surfaces (hard vs soft surfaces).

While possible (i.e. Dynamizers) Noise sources are usually not stored as part of the 3D City Model and are derived from other sources (i.e. road database, which includes speed limits, surface material and traffic count).

The calculation of the noise propagation is performed in a dedicated software. An ETL process, combining different sources and preparing a suitable input format for the software is required. For performance benefits, a lower LOD of the city model is usually preferred.

→ requires semantic information about hard vs soft surfaces → requires informatio about speed limit etc on street → external reference

Relevant Modules: Building, Vegetation, Transport, CityFurniture (Walls) Relevant Properties: Acoustic Surface Properties

7.2.5.  Flood Simulation

In some locations, flood simulations are an essential part of urban planning and emergency precaution.

The main input to the simulations are terrain and 3D objects (i.e. buildings). For more accurate calculations, information on ground roughness and infiltration capacity (permeable vs impermeable) are required.

While the simulation could theoretically be ran on a 3D City Model, the common hydorological models and simulation softwares rely on homogenous and continous raster DTMs as input.

These are in practice derived from a rasterized top view of the 3D objects (i.e. Buildings) combined with a DTM and (if applicable) additional raster layers describing surface coverage and permeability.

Required Modules: Building, CityFurniture Optional Modules: Vegetation

7.3.  Summary of required Information

Table 1

Use Case2nd Level Information (i.e. rooms)surface semantics (i.e. roof, windows)
Urban Plan Communicationnot requirednot required
Comprehensive Planningbenefitialnot required
Sight Analysisnot requirednot required
Shadow Analysisnot requirednot required
Solar Potential Estimationnot requiredbenefitial
Daylight Simulationoptionalrequired
Noise Simulationnot requiredoptional
Flood Simulationnot requiredoptional
Urban Climate Indicatorsnot requiredoptional
Indoor Wayfinding (First Response)requirednot required
Facility Managementrequirednot required
3D Cadastrerequirednot required

8.  Conclusion (Qualitative)

  • Buildings ist most used Module in the CityGML Data Model for 3DCIM applications

  • 2nd Level Building features (Rooms, Storey) are not yet widely used in practice, but cities are planning to use it and use cases have been described

  • Semantic Surface Information (especially “windows”) are required for certain Simulation applications and improve the results of others. However, currently most existing 3D city models do not contain semantic information on surfaces. Some models do differentiate between “Roofs” and “Walls”, but not “windows”. This is mostly due to the fact that aquiring this information requires either a semantically correct BIM model as a source (for newer buildling), or an established workflow to derive this information from other sources (i.e. photogrammetry, street images)

  • Some use cases require information that are usually stored in dedicated systems, (i.e. traffic, demographics), rather than maintaining a semantically thick data motdel, real world applications suggest the use of external references

  • Simulation which requires surface semantics often requires specific file format as input, hence a convertion is needed

→ show diagram, sources

Summary of Requirements as a Table

9.  Clause containing normative material — Minimal Profile

9.1.  Modules

The CityGML Best Practice Guidance document provides an overview of how various CityGML modules align with the CityGML Standard.

CityGML encompasses several modules. The overall CityGML data model is thematically decomposed into a CityGML core module and extension modules. Each module is defined within its own globally unique XML namespace. Due to this modularization approach, there are various versions of valid CityGML documents are not valid CityGML 1.0.0 instance documents. As a result the Best Practice Guidance documents details varying levels of support:

The document also notes that database solutions are specific, and alternative methods are recommended for formats like RasterRelief that are not supported.

Table 2

CityGML moduleIncludedComment
CorePARTIALNURBS are not supported, Implicit Geometries are not supported .ExternalReferences are not supported.
AppearancePARTIALthe CityGML class TexCoordGen is not supported, ie one must specify the UV coordinates in the texture files.
BridgeYES
BuildingYES
CityFurnitureYES
CityObjectGroupPARTIALgroups of City Objects are supported, but not groups of parts of objects (eg it is not possible to group some walls of a building together)
ConstructionPartialSemantic surfaces are not supported
DynamizerNOSemantically thin, dedicated systems
GenericsYES
LandUseYES
PointCloudNO
ReliefNoonly the TINRelief/TriangulatedSurface is supported.
TinNO(where only elevation points and break lines are stored) is not supported since it would require viewer/applications to have a constrained Delaunay triangulator, which is problematic (especially for web-based tools). Also, it is not possible to store areas over a terrain that would support different resolutions.
RasterReliefNOis also not supported → other, better formats?
TransportationTBD
TunnelTBD
VegetationYES
VersioningNOCityJson using git based approach, Database specific solutions?
WaterBodyTBD

9.2.  Required Modules

9.2.1.  Building Module

Applications must partially support the buildings module to comply with this profile.

Building & Building Part Applications must support the TopLevelFeatureType “Building” as well as the FeatureType “BuildingPart”.

Storeys & Rooms Applications may support the FeatureTypes “BuildingRoom”, “BuildingUnit” and “Storeys”

Storeys & Rooms Applications may support the FeatureTypes “BuildingRoom”, “BuildingUnit” and “Storeys”

Constructive Applications may support the FeatureTypes “BuildingContructiveElements”, “BuildingInstallation” and “BuildingFurniture”

 

UML of class Building

Figure 1 — UML of Building Module

9.3.  Optional Modules

9.3.1.  CityObjectGroup

The support of the “Constructions”"module is not required for compliance with this profile.

9.3.2.  Construction Module

The support of the “Constructions”"module is not required for compliance with this profile.

 

UML of class Construction

Figure 5 — UML of Construction Module

9.3.3.  Relief

  • Tin: Support is impractical due to constraints with Delaunay triangulation.

  • RasterRelief: TINRelief/TriangulatedSurface is supported; alternatives for unsupported formats are suggested.

9.3.9.  Appearance

The support of the “Constructions”"module is not required for compliance with this profile.

9.4.  Excluded Modules

Excluded from this profile. The following modules are not considered in the context of this best practice document

9.4.1.  Versioning

The Versioning module is excluded from the scope of this profile. It is recommended to rely on a external version control (git) or database system to handle version control.

9.4.2.  Point Cloud

The Point Cloud module is excluded from the scope of this profile.

9.4.3.  Dynamizer

The Versioning module is excluded from the scope of this profile. It is recommended to rely on dedicated systems / records for this kind of data.

9.5.  Geometry Objects

9.5.1.  Geometry Types

The CityGML Conceptual Model does not put any restriction on the usage of specific geometry types as defined in ISO 19107. For example, 3D surfaces could be represented in a dataset using 3D polygons or 3D meshes such as triangulated irregular networks (TINS) or by non-uniform rational B-spline surfaces (NURBS).

In order to improve interoperability and facilitate implementation, this profile restricts to the use of 3d polygons and 3d meshes.

9.5.2.  Implicit Geometry

Geometry shall be explicitly defined and may not be implicit.

9.6.  CRS

All CityObjects shall use the same CRS.

The coordinate reference system (CRS) shall be defined as a URL formatted according to the OGC Name Type Specification:

http://www.opengis.net/def/crs/{authority}/{version}/{code}

where {authority} designates the authority responsible for the definition of this CRS (usually “EPSG” or “OGC”), and where {version} designates the specific version of the CRS (“0” (zero) is used if there is no version).

A projected, cartesian coordinate system shall be used.


Annex A
(informative)
Conformance Class Abstract Test Suite (Normative)

NOTE:    Ensure that there is a conformance class for each requirements class and a test for each requirement (identified by requirement name and number)

A.1.  Conformance Class A

A.1.1.  Requirement 1

Requirement A.1

Test purpose

Verify that…​

Test method

Inspect…​


Annex B
(informative)
Title ( {Normative/Informative} )

NOTE:    Place other Annex material in sequential annexes beginning with “B” and leave final two annexes for the Revision History and Bibliography


Annex C
(informative)
Revision History

Table C.1

DateReleaseEditorPrimary clauses modifiedDescription
2016-04-280.1G. Editorallinitial version

Bibliography

NOTE:    The TC has approved Springer LNCS as the official document citation type.

Springer LNCS is widely used in technical and computer science journals and other publications

– Actual References:

[n] Journal: Author Surname, A.: Title. Publication Title. Volume number, Issue number, Pages Used (Year Published)

[1]  OGC: OGC Testbed 12 Annex B: Architecture (2015).